Remarks 



Applicants respectfully request reconsideration. This amendment affects the 
application as follows: 

• Claim 1 has been amended; 

• The following remarks have been submitted. 

The Examiner has rejected claim 1 under 35 U.S.C. § 1 12, ]|1, as failing to 
comply with the enablement requirement. The Examiner has asserted that claim 1 
contains subject matter which was not described in the specification in such a way as to 
enable one skilled in the art to which it pertains, or with which it is most nearly 
connected, to make and/or use the invention. The portion of claim 1 at issue is the 
limitation, "a database that stores data bus information for a plurality of different types of 
data busses." The Examiner has asserted that this limitation is not supported by the 
specification. Applicants respectfully disagree. 

Contrary to the assertions in the Office Action, the database 44 is plainly 
described as storing information for "different types of busses." This characteristic of the 
database is supported, for example, at^21 of the published application: 

The database provides a repository for vehicle-specific data bus 
information. The information is gathered from vehicle manufacturers and includes 
proprietary data bus configurations for each vehicle make and model potentially 
served by the telematics application. 

A direct reading of the specification reveals that the database contains data bus 
configurations (plural) for different makes and models of vehicle. Therefore, the 
specification indeed does provide support for "a database that stores data bus information 
for a plurality of different types of data busses," as recited in claim 1 . 

Also supporting enablement is the fact that a stated purpose of the system 
disclosed is to simplify the development of telematics applications for working with 
different types of vehicles having different types of data busses. This problem is clearly 
described in the background section: 

Vehicle data bus architectures, and the data conveyed on the buses, are typically 
vehicle-dependent, or specific to the vehicle make and/or manufacturer. []f3] 

[...] 
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These differences in bus standards and bus data content give rise to an ever- 
increasing number of vehicle variants. This increasing number of variants 
presents a problem to the people who create telematics applications that use 
vehicle data to provide meaningful content. flj4] 

[-] 

Conventionally, application programmers often need an intimate understanding of 
each vehicle's data-bus architecture and associated knowledge in how to extract 
desired vehicle data from that architecture. This approach typically requires a 
substantial investment in time and cost for the programmer. In addition, the 
application generally requires customization from one vehicle make and/or 
model, to the next. This presents a problem in terms of application portability to 
all potential telematics platforms. fl[5] 

[...] 

What is needed and as yet unavailable is a telematics-based vehicle data 
acquisition architecture that enables telematics application programmers to 
develop applications that can extract vehicle data with generic data requests 
independent of the vehicle data bus architecture. The telematics-based vehicle 
data acquisition system described herein satisfies this need. flJ7] 

The instant application addresses this deficiency in the prior art by allowing 
telematics applications to be developed at a high level, "such that data requests may be 
made generically, or independent of the vehicle make or model." 1J22. The system 
responds to generic requests from telematics applications by reaching into the database 
44 to obtain vehicle-specific data bus information: 

The vehicle runtime library 28 then responds to the application request, at step 
204, by retrieving the proprietary vehicle data bus information from the remote 
runtime database 44. The information includes, for example, the data protocol 
type, the access method for the parameter, value addresses, shift and mask 
information, return value decoding methods, scaling and unit conversion, etc. 
[127] 

Therefore, the information retrieved from the database is selected from among 
information in the database for different types of data busses and is particular to the make 
and model of the vehicle on which the telematics application is being run. 

From a plain reading of the application, claim 1 provides support for "a database 
that stores data bus information for a plurality of different types of data busses." 
Therefore, claim 1 meets the requirements for enablement, and the rejection of claim 1 
under 35 U.S.C. § 1 12, ^fl, should be withdrawn. 

The Examiner has also rejected claims 2-4 under 35 U.S.C. § 1 12, ]fl, citing the 
same grounds as asserted in connection with the rejection of claim 1 . Since these 
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grounds for rejection have been overcome, the rejection of each of claims 2-4 under 35 
U.S.C. § 112,H1 should be withdrawn. 

The Examiner has rejected claims 9-14 under 35 U.S.C. § 1 12, |1, as failing to 
meet the enablement requirement. However, the Office Action has not supplied any basis 
for these rejections. Therefore, these rejections are improper and should be withdrawn. 

To the extent that the Examiner's objections to claims 9-14 derive from a recited 
step in claim 9 of "accessing [. . .] a database that stores data bus information for a 
plurality of different vehicle makes," Applicants refer the Examiner to the statements 
above in support of the enablement of claim 1 . 

The Examiner has rejected claim 1 under 35 U.S.C. § 1 12, \2, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which 
Applicants regard as the invention. The Examiner has asserted that claim 1 lacks 
antecedent basis for the term, "the application program." 

Applicants have amended claim 1 to correct this problem, by replacing the term 
"application program" with "telematics application." Antecedent basis for "the 
telematics application" can be found at line 3 of claim 1 as amended. With this 
correction in place, the requirements of 35 U.S.C. § 1 12, ^2 are satisfied and the rejection 
of claim 1 as amended under 35 U.S.C. § 1 12, ^[2 is overcome. 

The Examiner has rejected claim 1 under 35 U.S.C. § 103(a) as being 
unpatentable based on Klausner et al. (US 6748305B1, hereinafter, "Klausner") in view 
of Seashore et al. (US 5916286A, hereinafter, "Seashore"). Applicants respectfully 
submit that this rejection is improper and should be withdrawn. 

Both Klausner and Seashore have been discussed in Applicants' Amendment 
Accompanying RCE, dated December 1, 2006. Klausner teaches a method and device 
for storing data in a vehicle. The device includes a "memory medium" that is connected 
over a vehicle data bus to various sensors and subsystems. At various points in time, the 
memory medium can be updated to include a potentially wide variety of information 
about the vehicle, including the status of its systems, the driving characteristics of its 
operators, and even the environmental conditions to which the vehicle is subject during 
its time in service. 

Seashore discloses a hand-held diagnostic tool that can be configured to read 
vehicle information (Abstract). The diagnostic tool contains a memory into which codes 
can be stored for interacting with different vehicles. A user configures the diagnostic 
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tool for interacting with a particular vehicle by selecting that vehicle type from the 
diagnostic tool's user interface. The diagnostic tool can then read information stored in 
the vehicle. See Fig. 4 and Col. 3, lines 6-24. 

The Amendment Accompanying RCE pointed out aspects of claim 1 that clearly 
distinguish over the combination of Klausner and Seashore, but which have not been 
addressed in the Examiner's arguments supporting the instant rejection. In particular, 
Applicants pointed out in the previous amendment that claim 1 recites a step of 

retrieving, responsive to the requests for vehicle parameter data from the 
application program, vehicle data bus information from a database that stores data 
bus information for a plurality of different types of data busses, the retrieved 
vehicle data bus information being associated with the type of data bus used on 
the vehicle on which the telematics application is executed 

In making the case for obviousness, however, the Examiner has omitted from his analysis 
the limitation that the retrieving step is "responsive to the requests for vehicle parameter 
data from the application program." 

As specified in MPEP 706.02(j), an office action must set forth the following 
elements to establish a prima facie case for obviousness under 35 U.S.C. § 103(a): 

(A) the relevant teachings of the prior art relied upon, preferably with reference to the 
relevant column or page number(s) and line number(s) where appropriate, 

(B) the difference or differences in the claim over the applied reference(s), 

(C) the proposed modification of the applied reference(s) necessary to arrive at the 
claimed subject matter, and 

(D) an explanation why one of ordinary skill in the art at the time the invention was 
made would have been motivated to make the proposed modification. 

The Examiner has made the assertion that "the method of acquiring vehicle data is 
responsive to the execution of a telematics application on a local telematics unit." 
However, that is a very general statement that does not address the particular limitations 
of claim 1 , as amended. By omitting from the analysis the limitation that the retrieving 
step is "responsive to the requests for vehicle parameter data from the application 
program," the Office Action has not made a prima facie case for obviousness under 35 
U.S.C. § 103(a). Therefore, the rejection of claim 1 as amended is improper and should 
be withdrawn. 
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As Applicants have pointed out, the fact that the retrieving step is "responsive to 
the requests for vehicle parameter data from the application program" represents a 
significant distinction. It is the application program's request for vehicle parameter data 
that causes the retrieval of vehicle data bus information specific to the vehicle of interest. 
This stands in contrast with Seashore, wherein a user manually selects a vehicle type. 
The specification provides a clear basis for this distinction at Fig 2 and paragraph 27: 

The vehicle runtime library 28 then responds to the application request, at step 
204, by retrieving the proprietary vehicle data bus information from the remote 
runtime database 44. The information includes, for example, the data protocol 
type, the access method for the parameter, value addresses, shift and mask 
information, return value decoding methods, scaling and unit conversion, etc. 

Neither Klausner nor Seashore discloses a step of retrieving vehicle data bus 
information responsive to requests from an applications program, as recited in claim 1 as 
amended. One simply cannot arrive at claim 1 as amended by combining Klausner with 
Seashore. 

Therefore, and for at least these reasons, the rejection of claim 1 as amended 
under 35 U.S.C. § 103(a) is overcome. Since claim 1 as amended has not been rejected 
on any grounds not already addressed, Applicants respectfully submit that claim 1 as 
amended is allowable. 

Claims 2-4 depend from claim 1 as amended. Therefore, claims 2-4 are allowable 
for the same reasons applied to claim 1 as amended. 

The Examiner has rejected claim 9 under 35 U.S.C. § 103(a) as being 
unpatentable based on Klausner in view of Seashore. Applicants respectfully submit that 
this rejection is improper and should be withdrawn. 

Claim 9 is directed to a method of acquiring vehicle data from any of a plurality 
of different vehicle makes. The claimed method includes the steps of "executing a 
telematics application on a local telematics unit operatively connected to a vehicle," 
"requesting vehicle parameter data by the telematics application," "accessing, responsive 
to the step of requesting vehicle parameter data, a database that stores data bus 
information for a plurality of different vehicle makes," "querying the database to retrieve 
data bus information for a particular vehicle make that corresponds to the vehicle," and 
"extracting vehicle data from a vehicle data bus using the vehicle data bus information" 
[emphasis added]. 
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In formulating the rejection of claim 9, the Examiner has not considered the 
portion of claim 9 emphasized above in italicized, bold print, which Applicant presented, 
discussed, and identified as significant in the preceding amendment. The Office Action 
does not identify any aspect of Klausner or Seashore that corresponds to the steps in 
claim 9 of "requesting vehicle parameter data by the telematics application" and 
"accessing, responsive to the step of requesting vehicle parameter data, a database that 
stores data bus information for a particular vehicle make that corresponds to the vehicle." 
Therefore, the Office Action has not made a prima facie case for obviousness under 35 
U.S.C. § 103(a). See MPEP 706.020"). Therefore, the rejection of claim 9 under 35 
U.S.C. § 103(a) is improper. 

In addition, Klausner and Seashore, taken separately or together, fail to disclose 
the method recited in claim 9. One simply cannot arrive at claim 9 by combining 
Klausner with Seashore. 

Therefore, the rejection of claim 9 under 35 U.S.C. § 103(a) is overcome. Since 
claim 9 has not been rejected on any grounds not already addressed, Applicants 
respectfully submit that claim 9 is allowable. 

Claims 10-13 depend from claim 9. Therefore, claims 10-13 are allowable for the 
same reasons applied to claim 9. 

Conclusion: 

Applicants contend that the application is now in condition for allowance. A 
notice to that effect is earnestly solicited. 

Respectfully Submitted, 

/Bruce D. Rubenstein #39,349/ 

Bruce D. Rubenstein 
Reg. No. 39,349 
Attorney for Applicant 
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